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be considered during the formulation of the 
program and not later when the program 
structure is in place and the program is in 
progress. Change is almost always costly; re- 
quirements traceability provides a bulwark 
against which the program manager and the 
systems engineer can stand and defend. 

Baseline Cost, Schedule 
and Performance 

The three main parameters in the control 
process — cost, schedule and performance — 
are the program manager’s bread and but- 
ter. Again, program definition is vital and 
necessary from the very beginning. It may 
be argued that clear definition is not possi- 
ble, particularly early in the program; nev- 
ertheless, an approved, traceable baseline, 
although it may alter, must be known at any 
given time, and must include everything in 
the program. The “I forgots” can kill you. 
The key to success in handling these three 
parameters is to manage the balancing act 
between them. Cost, schedule and perfor- 
mance are usually dependent variables and 
at various times, one or another may assume 
greater or lesser importance. A single vari- 
able, however, should never be changed 
without knowing the impact on the other 
two. Within the NASA culture, performance 
is generally the predominant factor, and 
schedule is a distant second. Cost tends to be 
considered mostly in the context of the annu- 
al appropriation, but from the point of view 
of the program manager, all three param- 
eters must be defined and approved continu- 
ously, which is a function of the systems en- 
gineering process. 

Program Risk Analysis 
In recent years, especially since the Chal- 
lenger accident, program risk analysis has 
come to be used largely in the context of crew 
safety, but this is only a part of program 
risk. Basically, program risk analysis asses- 
ses the probability of meeting requirements 
as changes occur. A number of analytical 
tools now available can be used to under- 
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stand the relationships between cost, perfor- 
mance and schedule. Again, a small group 
within the systems engineering organization 
should be dedicated to understanding the 
impact of any change on all three param- 
eters. Armed with this information, risk can 
be reduced in many ways. Adding more mon- 
ey, reducing the performance requirements, 
or extending the schedule are most often 
used. A competent systems engineer will 
know the relationships between these three 
variables and the impact of any situation on 
the total program. 

The Role of Cost in Phased Procurement 
The most common form of procuring high 
technology capability within the Federal 
Government is known as phased procure- 
ment. The theory behind this procurement 
method is that commitment to the program 
gradually increases with time and in dis- 
crete stages. Within NASA, there are four 
standard phases; others are beginning to 
creep in as the ability to establish new pro- 
grams becomes more difficult and the dura- 
tion and cost of operations becomes a more 
significant part of total program costs. The 
role of cost is different in each of the phases. 
The phases are: 

Pre-Phase A: This is a very unstructured 
period that examines new ideas, usually 
without central control and mostly ori- 
ented toward small studies. This period 
can last for a decade or more and produces 
the list of ideas and alternatives from 
which new programs are selected. 

Phase A: Sometimes called the feasibility 
phase, this is a structured version of the 
previous phase. Usually a task force or 
program office is established, and multi- 
ple contracts will be awarded. The goal of 
this phase, which may last for several 
years but usually is limited to one or two 
years, is to decide whether a new pro- 
gram will be started and what its purpose 
and content should be. This phase repre- 
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sents less than one percent of the total 
program costs. Nevertheless, it is largely 
a systems engineering effort and sets the 
stage for everything that follows. 

Phase B: Sometimes known as program 
definition, this phase is the most impor- 
tant in establishing the basic parameters 
of the program. By the time this phase is 
finished (a period of two or three years), 
the program rationale, cost, schedule, 
performance, management style and the 
most likely technical solution will have 
been established. This phase usually in- 
volves multiple contracts to establish a 
variety of ideas and a competitive envi- 
ronment, should the program proceed. 
Cost is continuously assessed as a func- 
tion of design solutions relative to basic 
requirements. Studies indicate that from 
five to ten percent of the total program 
costs will need to be expended if control is 
to be maintained over the program dur- 
ing Phases C and D. 

Phase C/D: Originally separate phases, 
this period covers design, development, 
test and evaluation. Contracts may be 
open to all qualified bidders or only to 
those involved in the previous phase. Al- 
though competition is not usually open 
between Phases C and D, commitment to 
Phase D depends on a successful and ac- 
ceptable design. In past programs, two- 
thirds of the total program cost was ex- 
pended during this period. The systems 
engineering role has begun to shift to- 
ward systems specification and systems 
interfaces. The secret to cost control is a 
sound definition of end items and their in- 
terfaces with a tight hold on changes. 

Phase E: In most past programs, the oper- 
ations costs were less than 20 percent of 
the total cost. This was because there was 
a definite end to a relatively short-term 
program. In recent years, particularly in 
the manned programs, the length of the 


operational phase has increased signifi- 
cantly. In the case of the Shuttle, it could 
be conceived as indefinitely long. For this 
reason, life cycle costs should be a major 
consideration from the beginning. 

Selling the Program 

The definition of a new start within NASA 
varies by program and organization but can 
generally be said to occur at the beginning of 
Phase B. Prior to that time, the program 
manager is selling the program. The total 
expenditure of funds during the selling peri- 
od is usually far less than one percent of the 
final program costs; this is, however, when 
the basic parameters of the program are es- 
tablished. It is a time of building constitu- 
ents both inside and outside the Agency. As- 
suming that a feasible technical solution is 
available and an acceptable management 
scheme can be provided, much of the debate 
about whether a program should be ap- 
proved centers largely around the question 
of cost. Of course, with only preliminary de- 
signs available, only cost estimates can be 
made and these are obtained from standard 
cost models. 

Cost Estimating 

During Phase A of the program, when the 
most rudimentary designs are available, it is 
essential that program cost estimates are 
made before the program start can be autho- 
rized. Estimates are made using cost models 
that have been developed on the basis of past 
experience on similar programs. These 
models are among the most arcane devices 
invented by engineers, so a few words on 
how they work are appropriate. 

Past experience is captured by documenting 
the cost of each system on the basis of 
weight. Regression analysis is performed to 
determine a straight line log relationship. 
Once the weight of the system has been esti- 
mated, the cost can be determined. This esti- 
mate is multiplied by a complexity factor to 
allow for the risk associated with the select- 
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ed technology and may vary from as little as 
0.50 to 2 or more. This is repeated for each 
system, and the total becomes the baseline 
cost. This total is multiplied by a factor to al- 
low for systems engineering and testing by 
the prime contractor. This is known as the 
“prime wrap” factor and is again determined 
based on all relevant past experience. 

All prime contractor estimates are added 
and then multiplied by a second factor 
known as the “nonprime wrap.” This is the 
cost of government work. Finally, a reserve 
factor is used to allow for problems during 
the program. There are separate cost models 
for manned and unmanned programs, which 
are significantly different. In general, for the 
unmanned programs, about 40 cents of every 
dollar goes to hardware, and in the manned 
programs, about 20 cents. 

These cost models pose a great many prob- 
lems. First, they are normalized on the basis 
of weight. Clearly this is not valid in all 
cases, particularly structure. Second, they do 
not explain why the costs are what they are. 
Factors such as management style, procure- 
ment strategy and test philosophy are not 
differentiated. Third, they include all past 
experience, including errors and overruns. 
In this respect, these cost models assume no 
learning curve. As it was in the beginning, is 
now, and forever shall be! They must there- 
fore be used with great caution. From the 
systems engineer’s point of view, these cost 
models can be used to assess the relative 
costs of various design solutions; on an abso- 
lute basis, however, they are of little use. 

So far we have been able to make a tentative 
estimate of the cost of the flight system. To 
this must be added the cost of new facilities, 
including launch, test beds, flight oper- 
ations, networks and data reduction, among 
others, and finally the cost of operations. It is 
at this point that the program manager faces 


the first dilemma: What should be included 
in the program cost? That sounds like a sim- 
ple question, but it is complicated by the fact 
that not all costs are under the control of the 
program manager, nor is he or she responsi- 
ble for justifying all of the associated appro- 
priations. 

For example, launch costs are provided by 
the Office of Space Flight, network costs are 
provided by the Office of Operations, and civ- 
il service costs are provided by the research 
and program management fund managed by 
the Office of the Comptroller. New buildings 
are provided under the construction of facili- 
ties budget. In addition, most new program 
managers are surprised to find that a tax 
based on the number of civil servants work- 
ing on the program varies from Center to 
Center, and neither the number of people 
nor the level of tax is under the control of the 
program manager. Taxation without repre- 
sentation! Despite this dilemma, the systems 
engineer should include all of these factors 
in the cost estimate because the chosen de- 
sign will affect all of them; overall program 
costs are as important to the Agency as di- 
rect program costs. 

Program costs tend to be presented as only 
those costs that are under the control of the 
program manager. No matter how much this 
limitation is stated in presentations, it is as- 
sumed that it is the total program cost (espe- 
cially when it is a popular program) that has 
the support of the Executive branch, the 
Congress and other constituencies. It is no 
wonder that the average program increases 
in cost by a factor of about three from the 
time of approval to completion and that most 
program managers during this period are ac- 
cused of everything from naivete to self- 
deception to outright lies. There is the added 
ethical question that if all costs were actual- 
ly presented, the program would not be ap- 
proved! 
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Defining the Program 

This phase of the program, usually known as 
Phase B, will take from one to two years. The 
purpose is to take the various concepts con- 
sidered in Phase A and select a single valid 
solution. By the time Phase B is over, a clear 
set of requirements should be available with 
a complete set of functional specifications 
and a cost estimate based on preliminary de- 
sign concepts rather than on cost models. 
These are primarily produced by the systems 
engineering organization and include at 
least one preliminary design and selected 
technologies with well-understood risks as- 
sociated with those technologies. 

Don Hearth, former director of the NASA 
Langley Research Center, performed a study 
on how much this phase has cost for various 
past programs as compared to the success of 
the program in later phases. Success was 
measured as the ability to maintain perfor- 
mance, schedule and cost as determined at 
the end of Phase B. He concluded that the 
most successful programs spent between five 
and ten percent of the total program cost in 
Phase B. The scope was limited to unmanned 
programs, but the rationale can reasonably 
be extended to manned programs. 

Apart from establishing a credible function- 
al system specification, it is essential to de- 
termine the management structure, the pro- 
curement strategy and a baseline cost for the 
life of the program, including the cost of op- 
erations. Once again, the primary method 
for cost estimating is the cost model, but 
there should be sufficient detail available to 
check the model with bottom-up costs based 
on feasible design solutions. The systems en- 
gineer is responsible for comparing these 
two cost estimating techniques. It is unwise 
to proceed to the next phases unless some 
bottom-up cost estimating has been per- 
formed. 

Perhaps the most important product of this 
phase is a complete work breakdown struc- 


ture. Again, this is largely the responsibility 
of the systems engineering organization. 
The axiom to be followed is, “You cannot 
control what you have not defined.” 

Work Breakdown Structure 

Too often a program will be approved with- 
out a well-established work breakdown 
structure (WBS) describing the whole pro- 
gram, which inevitably results in large cost 
overruns. The WBS is the basis for the pro- 
curement strategy and often for the manage- 
ment structure. Without it, program 
changes will take place after the contractors 
are in place and have to be paid. Overlaps 
between contracts, as well as missing ele- 
ments and contract changes, are always ex- 
pensive. The following simple rules have to 
be followed: 

1. Each element of the WBS should contain 
a deliverable that can be defined. 

2. The sum of the WBS elements must be 
the total program. (Note that a given pro- 
gram manager may not have the respon- 
sibility for all elements, but they should 
each be defined and allocated.) 

3. Each deliverable should be accompanied 
by a cost and a schedule. The cost should 
include a reserve based on the estimated 
risk associated with that element, and 
the cost should be allocated to that ele- 
ment. 

As simple as these rules sound and as much 
as NASA requires contractors to adhere to 
them, the internal track record is dismal. We 
can go a long way toward containing costs if 
discipline is established early and main- 
tained. 

One last word of caution. A WBS element 
should never be established on the basis of 
function or organization. These elements are 
not end items. Other mechanisms exist for 
identifying these elements, which in general 
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could be defined as program overhead and 
not entirely the responsibility of the pro- 
gram manager. They should be recognized 
for what they are and identified, but they 
should not be included in the WBS. 

Managing the Program 

We have now reached the time in the pro- 
gram when promises have been made, deals 
have been struck, and the program has been 
approved. All that remains is to deliver. A 
custom within NASA stipulates that new 
managers are instilled with the belief that 
the skills required to sell a program and to 
define it are different than those required to 
run it. Certainly some changes can be ex- 
pected, but I believe that such changes are 
better if they occur sometime after a phase 
has been entered and the basic management 
structures have been established. What the 
program needs at this time is ownership of 
the concept, and changes in management 
will usually result in program changes that 
inevitably will lead to increased costs. This 
is particularly true of the systems engineer- 
ing group that has carefully balanced the re- 
quirements against the design and is famil- 
iar with the “why” of a decision as well as 
the “what.” So far the total expenditure has 
been relatively low, but once the contractors 
are onboard and the manpower begins to 
build up, costs can escalate at an alarming 
rate. In a very short time, increases or de- 
creases in performance, extensions or reduc- 
tions in schedule, and decreases in annual 
funding will all increase cost. 

Design to Cost. There is much talk about 
design to cost but very little action, and for 
this there are a number of reasons. Earlier, I 
mentioned that within NASA there is a ten- 
dency to order the three variables by perfor- 
mance first, schedule second, and only then 
worry about cost. So by tradition, cost tends 
to be put on the back burner. One of the rea- 
sons for this is that during the Apollo pro- 
gram, the cost function was transferred to 
the budget and program control groups. In a 


program where the technical problems were 
so difficult and the budgets were ample, this 
was understandable, but this is no longer the 
case. This situation resulted in a shift away 
from making the design engineer account- 
able for cost as well as performance and 
schedule. 

The second problem occurs when the cost is 
not allocated at the WBS element level, 
where it can readily be traded against per- 
formance and schedule and easily traced. I 
believe that cost must be allocated to the 
lowest possible level (a little scary for the 
program manager), but unless this is done, it 
will be impossible to hold the designer ac- 
countable and unlikely that overall costs 
will be held in check. 

The third problem is that in an organization 
that prides itself on technical excellence, it is 
very difficult not to make things a little bet- 
ter, consequently, there are always plenty of 
ideas around. The credo of the systems engi- 
neer should therefore be: “The better is the 
enemy of the good.” 

Design to Life Cycle Cost. Over the past 
decade, the operational costs of NASA pro- 
grams have steadily risen as a percentage of 
total program costs, largely due to the fact 
that programs have a longer life in the oper- 
ational phase. Whereas 20 years ago oper- 
ational costs amounted to no more than 20 
percent of costs, they are now approaching 
half of the NASA budget. It is time to place 
design to life cycle cost on an equal footing 
with design to cost. The dilemma is that a 
design that allows low-cost operations will 
usually demand higher development costs 
and in turn, this means larger front-end pro- 
gram costs. It is essential that the systems 
engineer make these assessments. The sim- 
plest thing for a program manager to do is 
walk away from this dilemma and let the op- 
erations people worry about it later. As this 
is becoming an overall problem for the Agen- 
cy, the ability to make new starts will de- 
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pend on the ability to ensure that a sufficient 
percentage of the budget is available for op- 
erations. 

Unfortunately, it is difficult to get enough 
operations people to participate early in the 
program, but I believe it is essential. Some 
kind of veto power should be established 
when it comes to making design decisions; 
too many program managers do not feel re- 
sponsible for operations costs and perhaps, 
what is worse, are not held accountable for 
it. Let there be no doubt that operational 
costs are unacceptably high. An operational 
concept must therefore be developed early 
enough in the program to have an effect on 
the design process. 

Change Control. Once a program is under- 
way, the program manager’s responsibility 
is controlling change, which is inevitable. 
Earlier I said that you cannot control what 
you have not defined. It is equally true that 
you cannot control changing something that 
is not defined. First know what it is! A com- 
plete WBS with allocated schedule and cost 
is, once again, the key. Change requests 
must not be limited to solving a technical 
problem. They must be accompanied by cost 
and schedule impacts and, just as important, 
life cycle cost impacts. 

In addition, there is always a rippling cost 
impact caused by change. Other WBS ele- 
ments may be affected, including items in 
different contracts or in totally different 
NASA codes, or line items. For these rea- 
sons, change must be assessed at the systems 
engineering level as well as at the WBS lev- 
el. Perhaps the overriding rule is that 
changes should be difficult to approve but 
easy to implement once the decision is made. 

Managing Cost Reserves. A qualified cost 
estimator would not let a program get start- 
ed without making provision for cost over- 
runs or reserve. The many uncertainties in a 
development program make it essential. An 


analysis of past programs allows a fairly ac- 
curate estimate to be made of what is a rea- 
sonable total amount as a percentage of total 
costs, assuming that the programs are simi- 
lar. Determining how and when the allow- 
ance should be allocated is much more diffi- 
cult. One school of thought says that re- 
serves should be held at the highest level in 
the program and applied only to correct un- 
foreseen occurrences. The problem is that 
this tends to bail out poor performers. 

I believe that the reserve should be deter- 
mined based on the perceived risk of the ele- 
ment when the WBS is formulated. The 
manager of the element should then be held 
responsible for the stewardship of the re- 
serve. In order for this to work, some sort of 
reward system must be established for the 
manager who does not spend the reserve. In 
any case, it would be prudent to maintain 
some reserve at the central level for those 
things that cannot be anticipated. Just to 
keep the system honest, a very simple track- 
ing program can be established to follow the 
expenditure of the reserves at the WBS ele- 
ment level after the fact. I would like to see 
an indepth study done on this subject. 

Traps and Pitfalls 

So far we have talked about where cost fits 
into the program management and systems 
engineering processes. There are a few areas 
that may catch the program manager unpre- 
pared and a few ideas that may be used to 
make life a little easier in the future. It may 
not be possible to implement all of them, but 
it is worth a try. 

Buying In. If you are involved in the selling 
of the program, the easiest trap to fall into is 
underpricing the program. Despite stories to 
the contrary, I do not believe that this is a 
matter of deliberate low bidding. Although I 
once heard a distinguished gentleman say 
that we do business the old fashioned way, 
we do underbid and make up on change re- 
quests. The fact is that every program man- 
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ager I have ever met was convinced that he 
or she could do it for less than the past record 
would suggest. Unfortunately, this usually 
involves changing the way we do business. I 
believe that there are less expensive ways, 
but you should tackle this one at your own 
risk and only if you have the support of the 
very top of the organization. The systems en- 
gineer must be the conscience of the program 
manager during this period. 

Design to Budget. Let us assume that we 
have completed a perfect Phase B and that 
everything is in place, including the rate of 
expenditure by year. It is a virtually certain 
that two things will happen. First, with elo- 
quent rationales and spreadsheets by the 
ton, the various element managers will find 
a need to increase their funding allocation. 
One favorite argument will be that the sell- 
ers of the program, who are no longer in 
charge, will be blamed for not understanding 
the problem. In addition, Congress may add 
a requirement or two. 

Second, the budget will be cut in the Agency, 
at the Office of Management and Budget, 
and finally in Congress. At this point, the in- 
tricate patterns of dependency between per- 
formance, cost and schedule begin to un- 
ravel. In the first year, this is not devastat- 
ing because you can always delay bringing 
the prime contractors on board. But by the 
time they arrive, the trap has been set for 
the most insidious form of management, de- 
sign to budget. Unfortunately, a fact of life is 
that very few research and development pro- 
grams have multi-year funding, and annual 
budgets will be less than planned. The net 
effect is that program costs will escalate, and 
enormous pressures will attempt to bring 
down the annual funding. 

The first remedy is to stretch the schedule, 
and the second is to reduce the scope of the 
program. You will no doubt find yourselves 
in this position, and you will receive a great 
deal of advice from the nonparticipants, but 


you should beware of “descoping.” A cursory 
examination of the cost models will show 
that in the manned programs, only 20 cents 
of every dollar go to hardware. (In the un- 
manned programs, the number is closer to 40 
cents.) Once the management structure is in 
place and the contracts have been awarded, 
virtually all of the other costs are fixed or 
very difficult to reduce. Take out all the con- 
tent and the program cost will still be 80 per- 
cent of the estimate! The lesson is that if you 
are forced to remove content, you should be 
sure to take out every cent that is associated 
with that content: prime wraps, nonprime 
wraps, test beds, personnel, and, if neces- 
sary, the kitchen sink. It will be difficult to 
find, but it will be worth the effort. 

If this were a mystery novel, it might well be 
called “The Case of the Missing 80 Percent.” 
Where does it all go, and why is it only 60 
percent for unmanned programs? Much of 
this is valid and accounts for systems engi- 
neering and integration at all levels of the 
program, including test and evaluation, op- 
erations, and many other things. But it also 
accounts for duplication of test facilities, 
overlaps between assignments, management 
style, inefficiencies and a host of hidden 
costs associated with maintaining the insti- 
tutions that are often invisible to the pro- 
gram manager. The systems engineer is re- 
sponsible for ferreting out the good from the 
bad. It is a simple fact that the first one per- 
cent reduction in these wraps (80 percent to 
79 percent) increases the amount of hard- 
ware by five percent (20 percent to 21 per- 
cent)! A 20 percent improvement in the 
wraps (80 percent to 60 percent) results in a 
doubling of the hardware (20 percent to 40 
percent) or cutting the program costs in half 
for the same amount of hardware! “Thar’s 
gold in them thar hills.” 

The UPN System. The NASA budget is pre- 
pared and submitted using a system of 
breakdowns known as the unique project 
number (UPN) system. All parts of the 
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Agency are required to report their annual 
needs on the basis of this system, including 
the program offices. From a program point of 
view, a fatal flaw in this process is the num- 
bering system, which generally describes 
functions rather than end items and is there- 
fore not in consonance with the principles of 
a WBS system. 

It is essential that the program manager be 
able to trace the equivalence of the UPN 
number and its corresponding WBS element. 
This will require a joint effort between sys- 
tems engineering and the program control 
people. Without this traceability matrix, the 
program manager will not know what is be- 
ing asked for or where the money is going. 
Too often the UPN number is perceived as 
directly equivalent to the WBS element, but 
this is very seldom the case unless the WBS 
is not end-item oriented. (The latter happens 
more often than it should.) One way to avoid 
this situation is to make the annual budget 
call for the program using the WBS system 
and then translate it to the UPN system for 
the purpose of aggregating the total NASA 
budget. I have never seen this happen. 

The Cost of Operations. I mentioned earli- 
er that the costs of operations are now about 
50 percent of the NASA budget. This is part- 
ly due to the increase in the operational life 
of a program and to the fact that we have not 
learned to design systems for operability. It 
has not been necessary in the past. It is also 
true that the productivity of the operations 
infrastructure has not been high on the pro- 
gram manager’s list. If we are to reduce total 
program costs, which are vital to the Agency 
and to the program, it is time to strike a new 
level of cooperation between these two nor- 
mally separate parts. The program and the 
systems engineer must assume a large part 
of the responsibility. 

The Institution and the Program 
Although not directly related to the systems 
engineering process, a number of things bear 


directly on the program and have a major ef- 
fect on the ability to perform the various pro- 
gram functions. These generally concern the 
relationship between the program and the 
institution. NASA was originally estab- 
lished using the resources of the National 
Advisory Committee for Aeronautics, known 
as NACA, an aeronautical research organi- 
zation that was seldom involved in large de- 
velopment programs. The budget was rela- 
tively small, and there were few contractors. 
In fact, all contracts were signed at the 
Washington office, the NACA equivalent of 
Headquarters. 

It quickly became apparent that, in addition 
to the research centers, a development cen- 
ter was needed. Goddard Space Flight Cen- 
ter (GSFC) was established to perform this 
function. This was rapidly followed by the 
Lyndon B. Johnson Space Center (JSC) in 
Houston, the George C. Marshall Space 
Flight Center (MSFC) in Huntsville, and the 
Jet Propulsion Laboratory (JPL) in Pasade- 
na. Almost immediately, GSFC and JPL be- 
came responsible for multiple unmanned 
programs, which were largely contained 
within a single Center, and JSC and MSFC 
became responsible for multi-center manned 
programs. In both cases, program offices 
were established and the Centers provided 
the resources, both personnel and facilities, 
to support the program. 

With the exception of JPL, which is a Feder- 
ally funded research and development center 
and operates outside the civil service system, 
all NASA personnel and basic facilities are 
funded separately from the programs in line 
items known as Research and Program Man- 
agement (RPM) and Construction of Facili- 
ties (CoF). Program-specific facilities are 
funded by the program and these facilities 
are most often operated by support contrac- 
tors, also funded by the program. This sys- 
tem was established so that the programs 
would be managed by government personnel 
who would rotate from program to program 
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and carry their experience with them. This 
worked very well until the late 1960s when 
the budget began to fall rapidly, and there 
was a significant reduction in NASA person- 
nel. 

By the early seventies, both the budget and 
the number of personnel had been cut in 
half, but the number of Centers remained es- 
sentially the same. The cost of maintaining 
the institution could no longer be sustained 
by the RPM and CoF line items. The solution 
was to tax the programs based on the num- 
ber of personnel that were applied to the pro- 
gram. Unfortunately, the program manager 
does not decide how many people should 
work on the program, which, by tradition, is 
the responsibility of the Center director. 
Neither does the program manager partici- 
pate in determining the level of the tax. 
These decisions, again by tradition, are 
made by the comptroller. 

Maintaining the Institution 

Unless the basic system of funding personnel 
is changed, the programs will most certainly 
be responsible for funding some of the insti- 
tutional costs that are not related to the pro- 
gram; the RPM budget will never be allowed 
to grow to compensate for this. The question 
is rather how large the institution needs to 
be to support the program and how that deci- 
sion is made. I mentioned earlier that the 
WBS should represent the totality of the pro- 
gram and should always describe deliver- 
ables; this problem runs counter to that prin- 
ciple. I believe that the solution lies in ac- 
cepting this cost for what it is, negotiating 
the level of tax with the program manager 
for the duration of the program, and taking 
it off the top each year. It may not be control- 
lable in the normal sense, but at least it is a 
known number. 

Personally, I believe that the Agency would 
be better served if the development centers 
were managed using an industrial funding 
system similar to JPL and many other gov- 


ernment facilities, including the Navy labs. 
But until that happens, it will be necessary 
to find some balance between the institu- 
tional and program needs. 

Management Stability 

Every program will change management 
during its life cycle. The common practice in 
NASA has been to make these changes de- 
liberately between phases. It is not uncom- 
mon to see as many as four different manag- 
ers during a program, including a specialist 
in closing off completed programs. The posi- 
tive side to this is that it is possible to match 
the needs of each phase of a program to the 
special capabilities within the Agency. The 
negative side is that each manager has a dif- 
ferent style, each program has different 
management needs, and often these do not 
match when the changeover occurs between 
phases. One way is not always right and an- 
other always wrong, but each is different, 
and changes even in management style can, 
and usually do, increase the cost of the pro- 
gram. The secret then is to stick with a team 
as long as possible, particularly the systems 
engineering team, something that is easy to 
say and difficult to do in these times of de- 
clining internal expertise and increasing re- 
tirements. 

The Tyranny of Experience 
Too often, you will find resistance to change 
in the way things are done. “We have always 
been successful (measured by performance) 
doing it this way, and its very dangerous to 
change winning ways.” “If it ain’t broke, 
don’t fix it.” “You get no credit for an on-time 
failure.” All true and at the same time, de- 
structive to valid new ways of doing busi- 
ness, especially when it comes to introducing 
more efficient or less expensive ways. When 
the space program started, we had no exper- 
ience and what followed was the most inno- 
vative and exciting period in the history of 
high technology programs. But now we have 
all that experience, and it has become a bur- 
den. By all means, you should keep the wise 
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heads around (they may still save you), but 
take advantage of the explosion in new tech- 
nologies and capabilities, which allows for 
things that we could only dream of 30 years 
ago. You should be careful before you intro- 
duce a change, but you should not dismiss it 
out of hand. 

Does It Matter? 

We have been in the civilian space business 
for almost 40 years, and time after time we 
have shown that we can rise to any chal- 
lenge and lead the competition, provided we 
have the resources. Time and time again the 
Federal Government has provided the re- 
sources. We have been the envy of the world. 
We have written the book on the subject, 
both from a technical and a management 
sense. 

Until now, it was enough to know that we 
were the best. There was no established com- 
petition, most of the money was spent inter- 
nally, and cost efficiency was second to per- 
formance. Some have characterized it as a 
Works Projects Administration (WPA) for 
the technologists! The problem is that in this 
era of budget deficits and trade deficits, 
there is not enough discretionary money to 
go around. Even without international com- 
petition, it would be imperative to get more 
out of our research dollars. The trouble is 
that we have learned profligate ways, as nei- 
ther the government nor the contractors give 
rewards for cost efficiency. While we were 


basking in this glory, the rest of the world 
has been catching up; they have read the 
book. The competition, supported by their 
governments, is getting good and fierce. 

But there is a difference; the competition be- 
lieves that the space business is here to stay. 
I said space business, but I meant commerce, 
and in commerce cost efficiency is para- 
mount. Do we still want to stay at the top, or 
are we ready to leave it to the rest of the 
world? Are we prepared to do what is neces- 
sary to stay in the game? After all, it’s only a 
space program. Does it matter? You bet! 

Can Anything Be Done? 

In this paper, I have attempted to show 
where cost fits into the space program’s engi- 
neering and management business. A combi- 
nation of things have placed cost at the bot- 
tom of the priority ladder except in matters 
of the inexorable annual budget. There are 
many ways to improve cost efficiency, some 
of which are available to the program man- 
ager. In the long run, it will take a concerted 
effort by all of us to make a difference. The 
Executive branch and Congress, together 
with industry and academia, must work as 
before, when we perceived that we were sec- 
ond. In the meantime, I hope that I have 
been able to give the budding systems engi- 
neer and program manager a few tips to do 
something about the problem of cost consid- 
erations. We can only do something about it 
if we want to! 
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